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Data Management System Concept 


The Data Management System is unique in the Space Station 

- It has no “function” like other subsystems, i.e., it does not generate a state 
vector, or maintain cabin temperature, or hold vehicle attitude, etc. 

The Data Management System provides a set of services for all other 
subsystems 

- Provides computational resources 

- Transmits commands, messages and data between application programs 

- It is the means by which avionic systems integration is accomplished 

Since every subsystem is dependent on the DMS, it was identified as a long 

lead item during Phase B studies not because it was technically difficult, 

but because it had to be ready before any other subsystem design could be 
finalized 

Any other Space Station subsystem can be modified, enhanced or replaced 
with new technology and only has to reverify a single interface with the DMS 

Before the DMS data bus network, processor, operating system or system 
software can be changed In any way, potential impacts to every subsystem 
must be determined 
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DMS Evolution Rationale 


DMS has been designed from the beginning to support growth and evolution 

Although the present design is limited in capacity, the basic architecture will 
allow expansion by many orders of magnitude 

The Space Station has the benefit of building on past experience in software 
intensive digital avionics systems 

- Hardware, system software and applications programs are being developed 
as independent layers 

- Permits replacement, or upgrade, of any one layer without impact to the 
others 

Fiber optic global data bus loading at MTC expected to be < 5% of its stated 
capacity, and the bus does have growth capability 

- Processors, system services and operating systems may change over the 
years 

- The data bus is like wiring in your house, you might add extension cords 
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DMS EVOLUTION LINKED TO STATION CONFIGURATION 

"FOLLOW-ON-PHASE" 
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The DMS Advanced Architecture Task 


• The time to consider evolution is during the original design phase 

• Although hard lines must be drawn and the final flight designs developed, 
growth and evolution paths can be defined based on technology projections 

• The DMS Advanced Architectures task at the Ames Research Center has 
been chartered by the Level 1 Space Station Engineering Office to evaluate 
potential candidates for DMS growth and evolution 

- Task includes: hardware and software technology, system software 
enhancement, payload augmentation and software tool evolution 

- Task is done in coordination with Johnson Space Center 

- Status reports presented to other Nasa Centers and contractors at 
quarterly SATWG meetings and monthly Architecture Panel telecons 

- Payload integration studies being done in cooperation with several Ames 
payload research scientists 

• An advanced development test bed is being assembled to support 

simulations and analytical studies with hardware and software evaluation 
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DMS TASK APPROACH 

INCREASING LEVELS OF FIDELITY 




Analysis/System Engineering 

• Document Review 

• Design Review Attendance 
® User Requirements 

• Payloads 

• Subsystem 

• Operations 
©Crew 


Simulation & Benchmarking 

• Network Simulation 

• Processor Performance Prediction 



Isolated Hardware Testbeds 

• 1553 Local Bus 

• FDDI 

•386/486 Platforms 


ADVANCEO-RISC 

PROCESSOR 



Integrated Hardware Testbeds 

• System Level Performance Issues 

• Software Engineering 



DMS Kit 

• Track SSF Design 

• Software Development 
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The DMS Advanced Architecture Task Status 

• Detailed evaluation of 386 processor selected for the Station EDP completed 

- Determined that flight processor will have 3 MIPS computational speed 
compared to 4 MIPS for commercial equivalent 

- Difference is due to absence of cache memory in flight unit 

• Recommended that Station Project Office not consider the 486 as a viable 
upgrade candidate 

- 486 has on-chip cache memory but it does not have parity 

- Flight units are susceptible to single event upsets (SEU) from high particle 
impacts and high density memory chips need parity or EDAC 

• Have arranged for early delivery of 586 chips from Intel for evaluation 

• Commercial version of FDDI has been received and evaluation tests started 

• Three advanced parallel processing systems developed by DARPA are being 
evaluated for increased computational capacity and fault tolerance 

• Technique for converting digraph models to fault trees for reliability analysis 
has been completed. Fault tree to digraph conversion now under consideration 
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DARPA iWARP PROCESSOR EVALUATION 
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Task to evaluate a DARPA-sponsored processor and 
software architecture for future Space Station Freedom 
DMS upgrades through applications testing. 

• Evaluation of iWarp integration into DMS baseline 
architecture. 

e Seven degree-of-freedom spatial motion planning 
application on the iWarp. 

• Complex sensor processing applications on the iWarp. 
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suitability as a processing device for space missions. 
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SOFTWARE ENGINEERING 

REAL-TIME-MULTI-PROCESSOR 

TESTBED 
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Real-Time 
user Domain 
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User Domain 
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Domain 


Domains can be 
totally autonomous 
or cooperate 


Memory and I/O can be shared 
between domains or locked 
down to a specific domain 
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NETWORKED PROCESSOR PERFORMANCE 


DESIGN ISSUE 

• SYNCHRONIZATION 

• FUNCTION LATENCY 

• PERFORMANCE BOTTLENECK 
•EXTENDED REQUIREMENTS 


EMULATION 
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DMS MODEL 
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DMS Advanced Architecture Task 92 Goals 


• Begin timing studies of the Station Lynx OS with Ada application programs 

• Start colaborative effort with UC-Davis on detailed evaluation of the Space 
Station Ada compiler 

• Initiate long term effort on techniques for dynamically updating DMS 
operating system 

• Continue evaluation of parallel processers and expand fault tolerant system 
investigations 

• Begin detailed testing of 586 processor 

• Prototype an end-to-end payload experiment to define DMS capabilities 
and limitations 

• Develop a detailed Ada model of the on-board RODB for use in cooperative 
Ames/JSC/UH-CL flight data base testing 

• Implement a multi-node test bed that emulates the flight configuration plus 
additional nodes for a payload command station, ground control console 
and advanced fault tolerant processors for growth potential 
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